I hadn’t been merging upstream changes while implementing, so I’m in the middle of merging them now...

Some things have changed in the past day-ish, watch out for incompatibilities/redundant re-implementations of these:

• -name and -port params are already in place in master; -ip param is parsed but not acted upon. add the supplied server to the ui #435 adds the passed server in the launch args to the connect list
• Add servers.txt so players can add an arbitrary amount of servers to the "Join Game" list #478 adds a server txt that will add all of the present servers to the connect list
• The base client executable has its own dedicated server now when running with -server

So -server has been added, I see.
From a quick look at the issues, it seems there are still a few world-related bugs remaining.

servers.txt is a nice addition as well.
It’s more user-friendly than -target.

It was partially affected by #495, but I was able to merge it without any issues.

is it still only LAN multiplayer only? or can worlds be opened up to more people?

It can be accessed from anywhere if you have a suitable network that can be accessed from the global internet (a network line that can open the specified TCP port).

In short, it's a regular server app.

oh damn. so i could run this on a vps?

Yes, but since it still uses a lot of Windows API internally (to maintain compatibility), it requires a Windows system or a system that includes Windows API to run.

I would like to eventually release a Linux version and put it into Docker.

i mean, i've tried it on linux and it works fine. i could try and create a docker image if you'd like

I would like to eventually release a Linux version and put it into Docker.

You can run it fine on Linux without a GUI launcher via umu

i mean, i've tried it on linux and it works fine. i could try and create a docker image if you'd like

seriously!
That's nice.

wine also works really well. tried lutris and has similar results to umu

Which one has a smaller image size?
wine or umu

wine iirc

Currently there are two approaches: the separated version (this pull request) and the -server option version (merged yesterday) that starts the client directly as a server. Which one should be prioritized?

The separated version modifies the world-saving logic and changes the startup logic, so integrating it into the client side would be a bit tricky.

Alternatively, it would also be possible to keep both.

Realistically speaking a completely separate Server executable should be our preferred way for this to work. The -server command line option is moreso jank and this is far cleaner.

If we're planning to merge the separated server in the future, I was considering removing the -server option and the unnecessary client-side logic as well. Would it be okay to leave them as they are for now?

If we're planning to merge the separated server in the future, I was considering removing the -server option and the unnecessary client-side logic as well. Would it be okay to leave them as they are for now?

Yeah

seems to be a bug where i cannot change the game's difficulty and enable some settings (trust players, pvp etc)


doing this all on a vps too

Sorry, that’s not written in the description, but it’s still a dummy for now.
It’s only included in the default server.properties generation ahead of time (so it can be implemented later).

doing this all on a vps too

Would it be possible to send the Dockerfile and docker-compose.yml?

doing this all on a vps too

Would it be possible to send the Dockerfile and docker-compose.yml?

not using a docker image, which is surprising. i took your pr build and ran it on my vps. works REALLY well, minus the default server settings being awful (peaceful mode, no pvp etc)

i'm a little confused, where do worlds get stored? the server seems to autosave but... not save anything?

nevermind, you have to create the Windows64/GameHDD directory manually.

Changed it so that GameHDD is automatically created if it does not exist.

If this is functional even with a few caveats I think we'd be okay to merge it in. Would rather have this be something everyone can help you with easily on main than leave you dangling in this PR for longer than needed if that's something you'd prefer. Otherwise no rush, we can wait for you to be ready.

When running this under Docker, how do I invoke commands to the server such as ban-ip? or is that impossible

When running this under Docker, how do I invoke commands to the server such as ban-ip? or is that impossible

By default std in is disabled so you need to enable it.
After starting with options, you need to specify the service and attach it.

tty: true
stdin_open: true

We'll commit these as defaults later.

i got a question about the server console commands, you've created new commands and such but i can also see inside MinecraftServer.cpp alot of existing/old commands?, like time, these arent currently connected to the terminal?

i got a question about the server console commands, you've created new commands and such but i can also see inside MinecraftServer.cpp alot of existing/old commands?, like time, these arent currently connected to the terminal?

Even though the function is available, I cannot use it because I have not registered it.
More will be added in the future!

Is there any reason for CLI specific commands rather than a unified command implementation? Bukkit/Paper/JE uses the concept of a CommandSender which can be the console or a player, and iirc there’s some base code in the project that could be used to accomplish something like that. It’d be better for maintainability to only have one set of commands if we can help it

please add a server properties setting that parses the world width into here

param->xzSize = 5*64; is chunk width
hell scale should be 8 for these large worlds

this value only effects newly generated worlds
Current limit seems to be 5*64 chunks hardcoded inside ChunkSource.h

large worlds seem like mostly ocean past the 54 chunk mark, im thinking theres another setting somewhere

To share my findings with server World size,
To set the size of newly generated words we can define that inside the current ServerMain.cpp here:

NetworkGameInitData *param = new NetworkGameInitData();
if (config.hasSeed)
{
	param->seed = config.seed;
}

+> //Set World Size For new Worlds
+> param->xzSize = 5*64; //(5*64);
+> param->hellScale = HELL_LEVEL_SCALE_LARGE;

param->saveData = worldBootstrap.saveData;
param->settings = app.GetGameHostOption(eGameHostOption_All);
param->dedicatedNoLocalHostPlayer = true;

LogStartupStep("starting hosted network game thread");
g_NetworkManager.HostGame(0, true, false, (unsigned char)config.maxPlayers, 0);
g_NetworkManager.FakeLocalPlayerJoined();

We can also expand small worlds already generated by setting some app options, also inside ServerMain.cpp:

app.SetGameHostOption(eGameHostOption_DoMobLoot, serverProperties.doMobLoot ? 1 : 0);
app.SetGameHostOption(eGameHostOption_DoTileDrops, serverProperties.doTileDrops ? 1 : 0);
app.SetGameHostOption(eGameHostOption_NaturalRegeneration, serverProperties.naturalRegeneration ? 1 : 0);
app.SetGameHostOption(eGameHostOption_DoDaylightCycle, serverProperties.doDaylightCycle ? 1 : 0);


+> //Upgrade World Size
+> app.SetGameNewWorldSize(64*5, true);
+> app.SetGameNewHellScale(HELL_LEVEL_SCALE_LARGE);

StorageManager.SetSaveDisabled(serverProperties.disableSaving);
// Read world name and fixed save-id from server.properties
// Delegate load-vs-create decision to WorldManager

Currently worlds beyond 64*5 chunks wide cannot be created because of a hardcoded limit inside ChunkSource.h
i think if we just bump this #define LEVEL_MAX_WIDTH (5*64) //(6*54) we can increase the world size further
Edit: raising the LEVEL_MAX_WIDTH seems to be crashing the server upon launch,

we just need to tie these values into a Dedicated Server Config file now so that we can easily define world sizes

I’m back from my business trip, so I’ll resume working on this.

Is there any reason for CLI specific commands rather than a unified command implementation? Bukkit/Paper/JE uses the concept of a CommandSender which can be the console or a player, and iirc there’s some base code in the project that could be used to accomplish something like that. It’d be better for maintainability to only have one set of commands if we can help it

Based on a quick investigation of the current implementation, it seems that while the original codebase has structures for invoking command functionality, it was not designed to be used directly from text input.

Changing this would require significant modifications to both Minecraft.World and Minecraft.Client.

For now, the input handling, text dispatcher, and command suggestion logic are implemented on our side as a CLI-style interface.

The actual command logic required for execution (such as give, kill, time, etc.) already exists in Minecraft.World, so for the time being I think it is acceptable to invoke those through execute.

Ideally, everything should be unified in the future (preferably sooner rather than later).

@codeHusky

Sounds good, that can be refactored in a follow up pr then

The latest changes should now be integrated!
Please try it out and let me know how it works.

please add a server properties setting that parses the world width into here

Added the option.
It also seems to work correctly with existing worlds.

would it be possible to add a server.properties setting for the max amount of breeding animals?

would it be possible to add a server.properties setting for the max amount of breeding animals?

They are currently defined as constants internally, so there are no plans to make them configurable.
If made configurable in the future, they will likely be placed in the config directory similar to PaperMC.

@codeHusky
I added a build step to Actions in preparation for integration.
Is that okay? If not needed, I can revert it.

We’re definitely going to need a separate dedicated nightly server release so that’s perfect! :)